inf2301fandomcom-20200213-history
Flow Control
=Flow Control= World without flow control Imagine a sender (host A) and a receiver (host B) communicating over a TCP connection. Everything works perfectly fine as long as the communication is happening at the same rate, but what happens when the receiving host is busy at receiving or is a slow receiver? This will eventually lead to filling up the receiving buffer and overflowing the connection, and it is absolutely critical to have a service to control the flow. How flow control works Flow control ''is the service that is provided by TCP to ... well ... control the flow of the communication. This service ensures that the possibility of overflowing the receiver's buffer is eliminated. It basically matches the sending rate of the sender with the reading rate of the receiving application. More technically this can be described by having the sender to maintain a variable called the '''receive window', which is a variable that is intended to give the sender an idea of how much spare room (free buffer space) that is available in the receiver. As the TCP is a full-duplex; both host A and host B needs to maintain a distinct receive window. Example scenario: Imagine host A is sending a large file to host B over a TCP connection. Host B will allocate a receive buffer to this connection; denote its size by RcvBuffer. From time to time, the application process in host B reads from the buffer. Define the following variables: · LastByteRead: the number of the last byte in the data stream read from buffer by the application process in B. · LastByteRcvd: the number of the last byte in the data stream that has arrived from the network and has been placed in the receive buffer at B. · RcvBuffer: Receive buffer. · Rwnd: Spare room left in receive window. Changes dynamically with time. As the TCP is not permitted to overflow the allocated buffer, we must utilize the following calculations: · LastByteRcvd – LastByteRead ≤ RcvBuffer · Rwnd = RcvBuffer – (LastByteRcvd – LastByteRead) The question with this model is really: “how does the connection use the receive window (Rwnd) to provide flow control?” Well, initially the Rwnd is set equal to the RcvBuffer. Host B is then updating the value of Rwnd and packs it with every segment it sends to host A. This way A will always have a pretty good idea of how much space that is left in the receive window. Host A will keep track of two variables: · LastByteSent: the last byte that is sent. · LastByteAcked: the last byte that has been acknowledged by the recipient. Obviously LastByteSent – LastByteAcked represents the amount of unacknowledged data that host A has sent into the connection. To ensure that flow control is maintained; host A must at all-time ensure that the following equation is true: · LastByteSent – LastByteAcked ≤ Rwnd Technical Problem: A minor technical problem occurs when in example the host B’s receive buffer becomes full (Rwnd = 0). After sending this information to the sender (host A), the host A stops sending data, obviously, as the buffer of B is full. Now suppose that even after reading data from buffer – B doesn’t have any messages to issue to A. A is never updated with information that B now is ready for more data, and host A is basically blocked from transmitting any more data. To ensure that this doesn’t happen host A keeps on sending data segments of one byte while the Rwnd equals 0 to get fresh acknowledgements from B with updated information about the size left in the receive window. Category:Alle Category:Fullført